Sterowanie MQTT na żywo

wskazówka

Kontrola MQTT na żywo jest przeznaczona do zdalnego sterowania. Aby wysłać harmonogramy z wyprzedzeniem, zobacz Sterowanie MQTT zgodnie z harmonogramem zamiast tego.

Ten przewodnik pomoże Ci skonfigurować MQTT na Twoim SmartgridOne Controller, aby zdalnie kontrolować i monitorować instalacje akumulatorów i paneli słonecznych.

Co potrzebujesz

1. SmartgridOne Controller z połączeniem z internetem.
2. Poświadczenia MQTT: Można je uzyskać, wysyłając e-mail na adres support@eniris.be.
3. Środowisko programistyczne Python (lub inny klient MQTT). Ten przewodnik wykorzystuje podstawowy przykład napisany w Pythonie, aby pomóc ci rozpocząć pracę z MQTT i wysyłaniem poleceń. Zalecamy użycie Pythona z uwagi na łatwość użycia, ale każdy inny klient MQTT jest wspierany.

Dodatkowe informacje

MQTT to szybki protokół komunikacyjny w internecie. Jest to system wiadomości publikacji/subskrypcji, który umożliwia bezpośrednie połączenie między Twoją maszyną a SmartgridOne Controller. Twoje zasoby klasyfikowane są w grupy: solarne, akumulatorowe, EV i HVAC.

Pierwsza konfiguracja (punkt wyjścia dla nowych użytkowników)

Mam SmartgridOne Controller, którego chciałbym skonfigurować do zdalnego sterowania MQTT.

1. Sprawdź swoją sieć

Upewnij się, że Twoja sieć pozwala na ruch sieciowy mqtt przez port 1883. Możesz to zrobić, używając polecenia:

nc -zv mqtt.eniris.be 1883

Jeśli to polecenie nie jest dostępne, możesz alternatywnie pobrać i uruchomić ten kod Python.

W razie wątpliwości skonsultuj się z inżynierem sieci lub tymczasowo użyj hotspotu 4G/5G swojego telefonu, gdy pojawią się błędy połączenia.

notatka

Gdy port 1883 nie jest dostępny w Twojej sieci, oferujemy zapasowy port 80. Może być on skonfigurowany w Twoim kliencie MQTT na późniejszym etapie tego podręcznika.

2. Dodaj swoje urządzenia

Zaloguj się do interfejsu uruchamiania i upewnij się, że urządzenia są dodane do SmartgridOne Controller.

3. Dodaj zewnętrzny sygnał MQTT

4. Włącz zdalny sygnał MQTT

Pole 'VPP ID' musi pozostać puste.

Czas oczekiwania dla mechanizmu awaryjnego informuje SmartgridOne Controller, jak długo powinien czekać na nowe polecenia. Kiedy SmartgridOne Controller przestaje otrzymywać polecenia, automatycznie przyjmuje strategię domyślną po tym czasie.

Następnie wybierz wszystkie urządzenia, które chcesz uwzględnić w Zdalnym Sterowaniu MQTT.

5. Zdalny sygnał został dodany

Interfejs Zdalnego Sterowania MQTT został teraz aktywowany na SmartgridOne Controller.

Jesteśmy teraz gotowi do wysłania kilku podstawowych poleceń, korzystając z prostego przykładu. Kolumna Status informuje, czy jakiekolwiek polecenie jest aktywne.

Skrypt demo w Pythonie

Dobrą opcją na początek będzie przetestowanie nowo skonfigurowanej integracji za pomocą prostego przykładu.

Ten kod testowy wykonuje prostą operację ciągłego wysyłania następujących poleceń:

• Akumulator: Ładowanie przy 5 kW
• Słońce: Ustaw moc na 0 kW

SmartgridOne Controller nieprzerwanie odpowiada komunikatem 'feedback' zawierającym obserwowane wartości mocy sieci i zasobów. Ta funkcja również została ujęta w tym przykładzie.

Proszę pobrać plik poniżej w preferowanym IDE Pythona. Wypełnij swój numer seryjny i poświadczenia MQTT i uruchom skrypt:

Gdy powyższe zakończy się sukcesem, możesz kontynuować wysyłanie innych rodzajów poleceń. Wszystkie polecenia opisane są w naszej dokumentacji Zdalnego Sterowania MQTT.

Dokumentacja MQTT do wysyłania poleceń

Ta sekcja szczegółowo opisuje format wiadomości MQTT oraz wymagania dotyczące ładunku do zdalnego kontrolowania polityki mocy na urządzeniach w sieci SmartgridOne Controller.

Temat MQTT

Temat MQTT używany do wysyłania poleceń jest skonstruowany w następujący sposób:

standard1/rp_one_s/remoteControlMetrics/'controller SN'

Gdzie 'controller SN' należy zastąpić rzeczywistym numerem seryjnym SmartgridOne Controller, który zamierzasz kontrolować.

Struktura ładunku MQTT

Polecenia wysyłane są jako ładunki JSON. Struktura ładunku ma na celu określenie różnych polityk zarządzania mocą i punktów ustalania dla różnych komponentów systemu inteligentnej sieci. Oto zarys ładunku z szczegółowymi opisami pól:

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {
        "<Component Policy>": "<Policy Type>",
        "<Component Power Setpoint>": <Setpoint in watts>
    }
}

Opis pól

wskazówka

Wiele typów urządzeń (np. akumulatory + panele solarne) można kontrolować jednocześnie.

• extraTags (Obiekt):
  • nodeId (String): Unikalny identyfikator węzła w sieci SmartgridOne Controller. Jest równy numerowi seryjnemu, a następnie '_site_0' dla większości urządzeń SmartgridOne Controller.
• time (Integer): Znacznik czasu Unix w sekundach wskazujący czas, kiedy wiadomość została wysłana.
• fields (Obiekt):
  • <Component>_policy (String): Typ polityki dla komponentu. Jest to opcjonalne, a jeśli nie jest określone, system wróci do domyślnego ustawienia SmartgridOne Controller.
  • <Component>_power_setpoint_w (Float): Pożądany punkt ustalania mocy w watach dla komponentu. Jest to opcjonalne i ma znaczenie tylko wtedy, gdy określona jest odpowiadająca polityka.

Komponenty i polityki

informacja

Zasoby tego samego typu (np. dwa akumulatory) będą traktowane jako jeden komponent. Na przykład, gdy zainstalowane są dwa akumulatory 5 kWh, będą one traktowane jako jeden akumulator 10 kWh.

Każdy komponent w obiekcie fields może zawierać politykę i punkt ustalania mocy. Można kontrolować następujące komponenty:

• solar_policy i solar_power_setpoint_w:

  • Kontroluje politykę generacji mocy słonecznej i punkt ustalania. Obsługiwane polityki:
    • Polityka punktu ustalania: Ustaw maksymalną moc produkowaną przez wszystkie podłączone instalacje słoneczne w całości. Pole solar_power_setpoint_w powinno być ustawione na limit mocy produkcji w watach.
    • Polityka ograniczenia zasilania: Produkcja mocy w pełnym wymiarze, zgodnie z bieżącymi limitami sieci.
    • Polityka kosztów: Umożliwia minimalizację kosztów (rynku EPEX Spot) przy produkcji energii słonecznej z wyprzedzeniem. Gdy występują ujemne ceny zastrzyku, ograniczamy produkcję do własnego zużycia. Gdy zarówno cena odbioru, jak i cena zastrzyku są ujemne, wyłączamy wszystkie instalacje słoneczne. Pole solar_power_setpoint_w jest ignorowane.
    • Polityka wyłączenia: Wyłącza wszelką interakcję dla wszystkich aktywów słonecznych. Uwaga: limity nie są chronione w tym trybie. Pole solar_power_setpoint_w jest ignorowane.

• storage_policy i storage_power_setpoint_w:

• Kontroluje politykę systemu magazynowania energii oraz tempo rozładowania lub naładowania.

  • Ustawienie polityki: Ustaw całkowitą moc ładowania (pozytywne ustawienie) lub moc rozładowania (negatywne ustawienie) dla grupy baterii. Gdy podłączonych jest wiele baterii, ustawienie jest dzielone na dostępną moc ładowania/rozładowania, aby równomiernie obciążyć baterie. Pole storage_power_setpoint_w ustawione jest na pożądaną moc baterii.
  • Koszt polityki: Umożliwia optymalizację kosztów za pomocą cen dnia następnego (rynek EPEX Spot) dla baterii, ładując je w tanich godzinach i wykorzystując energię w drogich godzinach. Pole storage_power_setpoint_w jest ignorowane.
  • Polityka samokonsumpcji: Umożliwia prosty algorytm samokonsumpcji na bateriach. Nadmiar produkcji słonecznej jest przechowywany w baterii, a gdy słońce zachodzi, energia pobierana jest z baterii. Pole storage_power_setpoint_w jest ignorowane.
  • Polityka wyłączona: Wyłącza wszelką interakcję dla wszystkich aktywów baterii. Uwaga: w tym trybie limity nie są przestrzegane. Pole storage_power_setpoint_w jest ignorowane.

• heat_pump_policy:

  • Przełącza systemy pomp ciepła w tryb włączony/wyłączony. Minimalny i maksymalny czas działania zawsze będą przestrzegane.
  • Koszt polityki: Umożliwia optymalizację kosztów za pomocą cen dnia następnego (rynek EPEX Spot) dla pomp ciepła. Lokalne algorytmy dynamicznego ustalania cen decydują o najlepszych porach włączenia.
  • Polityka samokonsumpcji: Włącza pompy ciepła, jeśli produkowany jest nadmiar energii słonecznej.
  • Polityka wyłączenia: Wyłącza pompy ciepła.
  • Polityka włączenia: Włącza pompy ciepła.

• switched_load_policy:

  • Przełącza systemy kontrolowane przez przekaźniki w tryb włączony/wyłączony. Może to być wbudowany przekaźnik lub przekaźniki podłączone do sieci.
  • Koszt polityki: Umożliwia optymalizację kosztów za pomocą cen dnia następnego (rynek EPEX Spot) dla przekaźnika.
  • Polityka samokonsumpcji: Włącza przekaźnik, jeśli produkowany jest nadmiar energii słonecznej.
  • Polityka wyłączenia:
  • Polityka włączenia:

• variable_power_load_policy oraz variable_power_load_power_setpoint_w:

  • Zarządza polityką zużycia energii przez pojazdy elektryczne oraz ustawieniem.
  • Ustawienie polityki: Ustaw całkowitą moc ładowania dla grupy pojazdów elektrycznych. Pole variable_power_load_power_setpoint_w jest ustawione na pożądaną moc ładowania.
  • Koszt polityki: Umożliwia optymalizację kosztów za pomocą cen dnia następnego (rynek EPEX Spot) dla baterii, ładując je w tanich godzinach. Pole variable_power_load_power_setpoint_w jest ignorowane.
  • Polityka samokonsumpcji: Umożliwia ładowanie, jeśli produkowany jest nadmiar energii słonecznej. Pole variable_power_load_power_setpoint_w jest ignorowane.
  • Polityka wyłączona: Wyłącza wszelką interakcję dla wszystkich aktywów pojazdów elektrycznych. Pole variable_power_load_power_setpoint_w jest ignorowane.

• site_policy oraz site_power_setpoint_w:

  • Zarządza limitami eksportu lokalizacji.
  • Polityka eksportu: Ustaw limit eksportu dla lokalizacji. Pole site_power_setpoint_w jest ustawione na limit eksportu.
  • Polityka domyślna: Przywraca limit lokalizacji do domyślnej mocy eksportu, ustalonej w konfiguracji kontrolera.

Kontrola urządzeń

Konkretne urządzenia mogą być również kontrolowane zamiast grup urządzeń na podstawie ich typów. Wiadomość ma identyczną strukturę:

• nodeId_policy oraz nodeId_power_setpoint_w

informacja

Kiedy dwa polecenia wysyłane są do tego samego aktywa (np. jedno polecenie specyficzne dla urządzenia do inwertera słonecznego oraz polecenie do wszystkich urządzeń słonecznych), metoda kontroli specyficznej dla urządzenia będzie miała pierwszeństwo przed kontrolą typu urządzenia.

Zachowanie awaryjne

Dla każdego komponentu, jeśli _policy i _power_setpoint_w nie są określone, system automatycznie użyje polityki awaryjnej skonfigurowanej w SmartgridOne Controller. Zapewnia to, że każde urządzenie lub grupa urządzeń działa bezpiecznie i nadal funkcjonuje, nawet jeśli konkretne instrukcje nie są dostarczane.

Jeśli żadne polecenie nie jest wysyłane w ogóle, po 60 sekundach (lub skonfigurowanym okresie czasu oczekiwania), domyślne polityki dla aktywów zostaną ponownie aktywowane.

Przykład ładunku

Poniżej znajduje się przykład ładunku do ustawienia różnych polityk i ustawień:

{
    "extraTags": {
        "nodeId": "OM12404080000000000_site_0"
    },
    "time": 1714652046,
    "fields": {
        "solar_policy": "setpoint",
        "solar_power_setpoint_w": 5000,
        "storage_policy": "setpoint",
        "storage_power_setpoint_w": -5000
    }
}

W tym przykładzie, moc solarna jest ustawiona na generowanie do 5000 watów, a system magazynowania energii jest ustawiony na ładowanie lub rozładowanie z szybkością 5000 watów, w zależności od znaku wartości ustawienia. Jeśli któreś z ustawień solar_policy lub storage_policy zostało pominięte, odpowiednie urządzenie powróci do domyślnych ustawień określonych przez SmartgridOne Controller.

Dokumentacja MQTT dla odbierania informacji zwrotnej

Sekcja ta przedstawia strukturę i zawartość wiadomości zwrotnych wysyłanych przez SmartgridOne Controller za pomocą MQTT. Wiadomości te są publikowane w temacie standard1/outbound/remoteControlMetrics/feedback/<Controller SN> po przetworzeniu polecenia.

Temat zwrotny MQTT

Temat zwrotny MQTT jest zbudowany następująco:

standard1/outbound/remoteControlMetrics/feedback/<Controller SN>

Gdzie <Controller SN> powinien być zastąpiony numerem seryjnym SmartgridOne Controller, który wysyła informację zwrotną.

Struktura ładunku zwrotnego MQTT

notatka

Wszystkie aktywa są grupowane według ich typu. Oznacza to, że dwie indywidualne instalacje słoneczne o mocy 3 kW będą traktowane jako jeden aktyw wielkości 6 kW.

Wiadomości zwrotne są sformatowane jako ładunki JSON. Te ładunki dostarczają szczegółowych informacji zwrotnych na temat stanu systemu po zastosowaniu poleceń ustawienia, uwzględniając limity sieciowe/urządzeń. Poniżej znajduje się struktura ładunku zwrotnego z opisami jego pól:

{
    "time": "<Unix Timestamp>",
    "data": {
        "state": {
            "grid": {
                "active_power_W": <Moc aktywna w sieci w watach>,
                "today_imported_energy_Wh": <Energie importowane w sieci w watogodzinach>,
                "today_exported_energy_Wh": <Energie eksportowane w sieci w watogodzinach>,
                "import_limit_W": <Limit importu w sieci w watach>,
                "export_limit_W": <Limit eksportu w sieci w watach>,
            },
            "vpp_id": "<Identyfikator Wirtualnej Elektrowni>",
            "storage": {
                "energy_stored_Wh": <Energia przechowywana w watogodzinach>,
                "energy_capacity_Wh": <Całkowita pojemność energii w watogodzinach>,
                "mean_soc_perc": <Średni procent stanu naładowania>,
                "active_power_W": <Moc aktywna w watach>,
                "executed_power_W": <Ustawienie mocy wysłane do urządzeń w watach>,
                "executed_policy": <Polityka wykonana przez kontroler>,
                "max_charge_power_W": <Maksymalna moc ładowania w watach>,
                "max_discharge_power_W": <Maksymalna moc rozładowania w watach>,
                "today_charged_Wh": <Energia naładowana w bieżącym dniu w watogodzinach>,
                "today_discharged_Wh": <Energia rozładowana w bieżącym dniu w watogodzinach>,
                "nr_devices": <Liczba kontrolowanych urządzeń magazynujących>
            },
            "solar": {
                "active_power_W": <Moc aktywna słoneczna w watach>,
                "executed_power_W": <Ustawienie mocy wysłane do urządzeń w watach>,
                "executed_policy": <Polityka wykonana przez kontroler>,
                "capacity_W": <Pojemność paneli słonecznych w watach>,
                "today_energy_Wh": <Energia wyprodukowana dzisiaj w watogodzinach>.
                "nr_devices": <Liczba zainstalowanych kontrolowanych urządzeń solarnych>
            },
            "heat_pump": {
                "executed_policy": <Polityka wykonana przez kontroler>,
                "operation_modes": <Tryby pracy pompy ciepła>,
                "executed_power_W": <Wartość mocy ustawiona i przesłana do urządzeń w watach>,
                "nr_devices": <Liczba zainstalowanych kontrolowanych urządzeń pompy ciepła>
            },
            "switched_load": {
                "executed_policy": <Polityka wykonana przez kontroler>,
                "devices_on": <Liczba uruchomionych urządzeń>,
                "devices_off": <Liczba wyłączonych urządzeń>,
                "executed_power_W": <Wartość mocy ustawiona i przesłana do urządzeń w watach>,
                "nr_devices": <Liczba zainstalowanych kontrolowanych urządzeń przełączalnych>  
            }
        },
        "response_code": <Kod odpowiedzi>
    },
    "fields": {},
    "requestTime": "<Znacznik czasu Unix>",
    "time": "<Znacznik czasu Unix>",
    "siteNodeId": "<SN kontrolera>_site_0"
}

### Opis pól
- time (Integer): Znacznik czasu Unix wskazujący moment, w którym wysłano wiadomość zwrotną.
- fields (Object):
    - state (Object):
        - vpp_id (String): Identyfikator Wirtualnej Elektrowni związanej z tym urządzeniem.
        - grid (Object):
            - active_power_W (Float): Reprezentuje aktualną moc czynną w sieci w watach.
            - today_imported_energy_Wh (Float): Całkowita energia pobrana z sieci dzisiaj w watogodzinach. Uwaga: Dziś podano w czasie UTC.
            - today_exported_energy_Wh (Float): Całkowita energia wprowadzona z powrotem do sieci dzisiaj w watogodzinach. Uwaga: Dziś podano w czasie UTC.
            - import_limit_W (Float): Limit importu w sieci w watach,
            - export_limit_W (Float): Limit eksportu w sieci w watach,
        - storage (Object):
            - energy_stored_Wh (Float): Aktualna ilość energii przechowywanej w watogodzinach.
            - energy_capacity_Wh (Float): Całkowita pojemność systemu magazynowania energii w watogodzinach.
            - mean_soc_perc (Float): Stan naładowania jako procent. To jest średnia ważona wśród wszystkich podłączonych baterii. (gdy jest podłączonych wiele baterii: np. bateria 'a' ma pojemność energetyczną 10 kWh i stan naładowania 20%; bateria 'b' ma pojemność energetyczną 20 kWh i stan naładowania 50%, to mean_soc_perc wynosi 40%)
            - active_power_W (Float): Aktualna moc czynna dla systemu magazynowania w watach, pokazująca tempo ładowania lub rozładowania.
            - max_charge_power_W (Float): Maksymalna moc, przy której magazyn może być ładowany.
            - max_discharge_power_W (Float): Maksymalna moc, przy której magazyn może być rozładowywany.
            - executed_power_W (Float): Suma całkowitej mocy żądanej do (roz)ładowania z aktywów magazynowych, przesyłana przez nasz algorytm sterujący. Dotyczy tylko, jeśli polityka 'follow_setpoint' jest aktywna.
            - executed_policy (Str): Polityki, które zostały zastosowane do kontrolowanych.
            - today_charged_Wh (Float): Całkowita energia naładowana do kontrolowanej baterii dzisiaj. Uwaga: Dziś podano w czasie UTC.
            - today_discharged_Wh (Float): Całkowita energia rozładowana z kontrolowanej baterii dzisiaj. Uwaga: Dziś podano w czasie UTC.
            - nr_devices (Int): Liczba kontrolowanych aktywów baterii.
        - solar (Object):
            - active_power_W (Float): Aktualna moc czynna generowana przez panele słoneczne w watach.
            - capacity_W (Float): Całkowita pojemność systemu generacji energii słonecznej w watach.
            - executed_power_W (Float): Suma całkowitej mocy żądanej z aktywów słonecznych, przesyłana przez nasz algorytm sterujący. Dotyczy tylko, jeśli polityka 'follow_setpoint' jest aktywna.
            - executed_policy (Str): Polityki, które zostały zastosowane do kontrolowanych.
            - today_energy_Wh (Float): Całkowita energia wyprodukowana z kontrolowanych aktywów słonecznych dzisiaj. Uwaga: Dziś podano w czasie UTC.
            - nr_devices (Int): Liczba kontrolowanych aktywów słonecznych.
        - heat_pump (Object):
            - executed_policy (Str): Polityki, które zostały zastosowane do kontrolowanych.
            - operation_modes (Str): Tryb pompy ciepła (Tryb blokujący, Tryb wspomagania, Tryb samodzielnego sterowania)
            - executed_power_W (Float): Oczekiwana moc, którą aktualnie wykorzystuje.
            - nr_devices (Int): Liczba kontrolowanych pomp ciepła.
        - switched_load (Object):
            - executed_policy (Str): Polityki, które zostały zastosowane do kontrolowanych.
            - devices_on (Int): Liczba uruchomionych urządzeń.
            - devices_off (Int): Liczba wyłączonych urządzeń.
            - executed_power_W (Float): Moc, którą aktualnie wykorzystuje (jeśli dostępna).
            - nr_devices (Int): Liczba kontrolowanych obciążeń przełączanych.
        - nodeId (Object):
            - Jeśli nodeId jest zawarte w poleceniu, odpowiedź będzie zawierała odpowiadający stan urządzenia.
    - response_code (Int):
        - Wskazuje status operacji. Kod odpowiedzi 0 zazwyczaj oznacza sukces, podczas gdy inne wartości mogą wskazywać różne rodzaje błędów lub informacje o statusie (te powinny być szczegółowo opisane w osobnym odniesieniu).

### Przykład ładunku odpowiedzi
Oto przykład wiadomości zwrotnej po poleceniu ustawienia różnych wartości mocy:

<ClickableImage src="/img/generic/mqtt-example-feedback.png" alt="Obraz 1" maxWidth="450px" />

Ta odpowiedź demonstruje aktualny stan operacyjny systemu po wykonaniu wartości ustawień, wskazując skutki dla generacji energii słonecznej, magazynowania i ogólnej interakcji z siecią.

## Obsługiwane wersje MQTT i zachowanie w przypadku nieautoryzowanych tematów
Korzystając z MQTT, ważne jest, aby uwzględnić różnice w specyfikacjach między wersjami 3.1, 3.1.1 i 5.0, szczególnie dotyczące zachowania brokera, gdy klienci publikują na nieautoryzowanych tematach.

Zgodnie ze specyfikacją MQTT 3.1.1 (patrz OASIS MQTT 3.1.1 Specification, sekcja MQTT-3.3.5-2), broker musi zakończyć połączenie, gdy klient wyśle PUBLISH do tematu, do którego nie ma uprawnień. Takie zachowanie może prowadzić do nieoczekiwanych rozłączeń dla klientów próbujących publikować na źle skonfigurowanych lub nieautoryzowanych tematach.

W MQTT 3.1 to wymaganie nie występuje. Gdy klient publikuje na nieautoryzowanym temacie w tej wersji, broker zazwyczaj ignoruje wiadomość (ciche odrzucenie) bez zakończenia połączenia. To sprawia, że MQTT 3.1 w niektórych przypadkach jest bardziej odpowiednie, gdy odporność na błędy konfiguracyjne lub tymczasowo brakujące uprawnienia jest ważniejsza niż ścisłe egzekwowanie bezpieczeństwa.

Chociaż MQTT 5.0 wprowadza możliwość pracy z kodami powodów (takimi jak PUBACK z powodem odmowy), wymaga to wsparcia zarówno po stronie klienta, jak i serwera. Migracja do MQTT 5.0 wiąże się z dodatkowymi wysiłkami w zakresie implementacji.

__Konsekwencje ignorowania kompatybilności:__
Jeśli klient łączy się przy użyciu MQTT 3.1.1 i próbuje publikować wiadomości do nieautoryzowanych tematów, broker nagle zakończy sesję. Może to prowadzić do niestabilności, utraty łączności lub zwiększonego obciążenia z powodu powtarzających się prób ponownego połączenia.

__Zalecane podejście:__
Dla systemów, w których klienci mogą (tymczasowo) próbować publikować do nieautoryzowanych tematów lub w których obsługa błędów nie jest ściśle wdrożona, zalecamy użycie MQTT 3.1. Gwarantuje to bardziej stabilne połączenia i unika niezamierzonych rozłączeń podczas działania.